home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93c.txt / 000022_icon-group-sender _Wed Jul 21 09:13:07 1993.msg < prev    next >
Internet Message Format  |  1994-02-02  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 08:44:20 MST
  2. Date: Wed, 21 Jul 93 09:13:07 CDT
  3. From: "Richard L. Goerwitz" <goer@midway.uchicago.edu>
  4. Message-Id: <9307211413.AA01333@midway.uchicago.edu>
  5. To: icon-group@cs.arizona.edu
  6. Subject: Icon for large-scale stuff
  7. Status: R
  8. Errors-To: icon-group-errors@cs.arizona.edu
  9.  
  10. >Some time ago I re-posted a message from the Linguist List having to do
  11. >with a linguistic software initiative.  I had wondered if (and suggested
  12. >that) Icon might become more 'popular' by showing utility in such an
  13. >initiative.
  14.  
  15. >One reply claimed that Icon would not have such utility since it could not
  16. >manage the massive amounts of data/calculations that are often required in
  17. >linguistic work.
  18.  
  19. Sounds pretty pessimistic.  In fact, I've been using Icon successfully
  20. on large corpora for several years now.  Naturally there are some things
  21. Icon does not do well.  Despite the natural tendency to be lazy, one
  22. really does have to maintain facility with several languages, both high
  23. and low-level, in order to be construct NLP tools quickly that can do
  24. the job.
  25.  
  26. One thing to remember is that NL stuff often involves constructing human-
  27. machine interfaces.  The software only has to be fast enough to map NL
  28. queries to some primitive set of instructions.  This can be done in real
  29. time using Icon-based tools.  NLP also may involve processing large cor-
  30. pora in batch mode.  Again, although Icon will not do this sort of thing
  31. as quickly as C, it's certainly no worse than LISP or Prolog, and these
  32. are two of the main languages used for such batch processing.  The idea
  33. is that it doesn't matter if the batch processing finishes in one minute
  34. or ten if it's really done in batch mode.  Response time is a problem
  35. more for interactive systems.
  36.  
  37. One final note I might inject here is that Icon performs perfectly well
  38. for multi-megabyte databases, especially under "real" operating systems
  39. with sensible file systems.  If you want evidence of this, ftp my silly
  40. "Bibleref" program from cs.arizona.edu.  This program can find a passage
  41. requested by the user, decompress it, and display it in just a few sec-
  42. onds.  It can perform word searches almost as quickly (unless you are
  43. looking for something like "the").  If I'd skipped the compression and
  44. decompression phases by using a straight, human-readable database, then
  45. the delays would have been even less.
  46.  
  47. I confess that there are certain projects I really wouldn't do in Icon.
  48. I discovered one seemingly complex phenomenon in one text to be, in fact,
  49. *almost* right linear, and decided that the natural parsing tool to use
  50. would be YACC + Lex.  Still, it is flatly wrong to claim that Icon would
  51. not be useful as a linguistic research tool.  The proof is in the pudding,
  52. and I have a lot of pudding on hand.
  53.  
  54. -Richard Goerwitz
  55.  goer@midway.uchicago.edu
  56.